POV-Ray : Newsgroups : povray.unofficial.patches : Seems that the tesselation patch died before even being born : Re: Seems that the tesselation patch died before even being born Server Time
2 Sep 2024 00:18:58 EDT (-0400)
  Re: Seems that the tesselation patch died before even being born  
From: Wlodzimierz ABX Skiba
Date: 19 Jan 2001 09:38:00
Message: <3a685148@news.povray.org>

> > well written documentation should have description what deform{} cause
>
> Yes. But that's probably for later...

but before publicity of code/patch

> > I plan support this built-in engine of warps
>
> That's a good thing!

Thanks redirected to Chris

> > Well, currently I play with pure mechanism of inheriting of textures
> > You can halp me with type of deformations
> > every deformations should have described four things
> > b) undeform function
>
> This limit you to inversable transformation.
> Beware, some warps have singularity...

please read explanation about it in my todays posts in p.u.p

> > a) deform function (with calculation of new normal)
>
> I am wrong in thinking that the deformation of the normal
> is simply the resulting deformation of both extremity ?

yes, you are wrong, there was some posts about this problem
in this group and in p.a-u

> > c) calculation of new bbox of deformed bbox
>
> Yes, not obvious for some deformation.
> But if you have a container object, I do not see the need
> for that.

I'm talking exactly about container bounding

> > d) calculations of begining and ending of ray crossing deformed shape (for
> > twisting it is cylinder)
>
> That's the all_intersection of the container, isn't it ?

not exactly, but mainly yes

> > for i=depth1 to depth2 step accuracy
>
> That was the reason of my 'Ouch...'
> It may slow down a lot!

not so much
less than the same thing realized with isosurface
more than the same thing realized with mash
but as you can observe my method has better accuracy than mesh

> > after advice of Chris Huff I plan to omit this limitations
>
> Which one ? the reversable transform ? How ?

there is more about my idea in p.u-p in todays posts

> > > > by spliting ray to short segments and deform them and intersect base
object
> > > Ouch...
> > sorry, what's wrong ? :-)
> I just imagined the explosion of additional rays to cast...

you only imagine but I have tested this
it is not so bad solution

> > > > http://www.abx.art.pl/pov/nonlinear/step3.jpg
> > >
> > > Nice!!!
> > > I can imagine how to do it with a warp-based mesh deformation,
> > > but you probably did it with a real checkered box.
> >
> > right, with uv-mapping
>
> Why ? a warp should have been enough...
> (deform the box, warp the texture, with the same equations...)

why ? just for test that uv-mapping works correct with my patch

> > new closing parts of functions called Parse_Object_Mod()
> > new CASE in Parse_Object_Mod()
>
> Here we had a little divergence of opinions, but
> please do it your way.

thanks

> > new field in ISTACK
> > new parameter to all All_Intersections with max_depth
>
> These I will probably not like either...

perhaps max_depth could be added to ray structure instead of all_intersections
I will check this

ABX


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.